home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0399 / 279 < prev    next >
Internet Message Format  |  1994-08-27  |  5KB
  1. From: mforget@elfhaven.ersys.edmonton.ab.ca (Michel Forget)
  2. Subject: Re: Shortcut Manager
  3. Date:     Fri, 3 Jun 1994 02:19:16 -0600
  4. Mime-Version: 1.0
  5. Precedence: bulk
  6.  
  7. In <memo.274025@cix.compulink.co.uk>, Andre Willey writes:
  8.  
  9. [Subject:  Re: Shortcut Manager]
  10.  
  11. [> In <9406021115.AA07464=avg@mijt.cwi.nl>, Annius.Groenink@cwi.nl wrote:
  12. [> 
  13. [> I disagree. The whole point is to keep the thing as *simple* as possible:
  14. [> define general operations, and if an application doesn't support that
  15. [> operation, don't load the shortcut. e.g. your example of DTP not needing
  16. [> the explicit codes for Bold, Italic, etc. Fine, so DTP programs don't load
  17. [> them. Equally, if we have a code for 'Font selector', that might not be
  18. [> required by a simple text editor, but a DTP program should support it.
  19. [> 
  20. [> Each program already *knows* what kind of application it is, and should
  21. [> understand which shortcuts it can viably support, and which don't apply to
  22. [> it.
  23.  
  24. Yes, I agree.  Since each application knows what it supports and what it
  25. does nto, it should only use the keyboard shortcuts for the general codes
  26. that it supports.
  27.  
  28. [> In <9406021218.AA07652=avg@mijt.cwi.nl>, Annius.Groenink@cwi.nl wrote:
  29. [>   
  30. [>   > Actually,  with the current easy of incorporating a resource
  31. [>   > in C  (Interface and RSH format)  I think all applications should
  32. [>   > protect their resources by including them into the binary. 
  33. [>   >  
  34. [>   > Who wants hacked versions of their software floating around? 
  35. [> 
  36. [> People in Germany who don't speak English, and vice versa? The RSC system
  37. [> does make basic translations a lot simpler.
  38.  
  39. It does; including a resource in your source code is not as easy as using
  40. a separate resource, and has the disadvantage of requiring a recompilation
  41. for even minor changes to the resource.  It also makes translation a lot
  42. harder to do (though some authors do not want their programs translated).
  43.  
  44. [> In <9406021212.AA07620=avg@mijt.cwi.nl>, Annius.Groenink@cwi.nl wrote:
  45. [> 
  46. [>   > Let's continue as follows:  we'll talk about what exactly we want in
  47. [>   > the KEYBIND.INF file,  and what not.  Then after a few days,  based
  48. [>   > on the results of that discussion,  I will put forward a definition
  49. [>   > of the file's syntax
  50. [> 
  51. [> Oh, you will, will you...?
  52.  
  53. I think Annius wrote that before your proposal; now that you have already
  54. proposed the syntax, there will be no need for anyone else to do so.
  55.  
  56. [> On the other hand, we could all discuss it here, then Ofir and I can make
  57. [> any agreed revisions and put it into his amended proposal for the group.
  58. [> 
  59. [>   > In a very simple formalism.  I'm convinced that we need to separate
  60. [>   > codes into default sections,  class dedicated sections and
  61. [>   > application-specific codes. 
  62. [> 
  63. [> I think I've covered that already. What we could do is to allocate
  64. [> blocks of numbers for very specific tasks, such as DTP, MIDI, etc.
  65. [> Would that make you happier? (e.g. 1000+ for DTP-oriented tasks, 2000+
  66. [> for MIDI, 3000+ for painting/photo/etc, 4000+ for Database, etc). Again
  67. [> I wanted to avoid making this too complex - if it's hell to work with, no
  68. [> one will bother.
  69.  
  70. As programmers, I do not think anyone will find this too complex.  It does
  71. not really matter how many codes there are, because the programmer would
  72. only have to deal with the codes associated with his own type of
  73. program.
  74.  
  75. [>   > I think we shouldn't use 'codes'.  Your formalism looks too much like
  76. [>   > ASSIGN.SYS,  which IMHO is hard to grab for a naive user (it is hard
  77. [>   > enough to understand for me!) 
  78. [> 
  79. [> Hence the comments at the end of each line, which could be in any language
  80. [> (or several, come to that). Parsing text is a waste of time for a program,
  81. [> and rather annoying for non-English speakers, I guess. Let's keep it plain
  82. [> and simple, and avoid creating something over-complex just for the hell of
  83. [> it. Otherwise we might as well end up writing the thing in COBOL...
  84.  
  85. I agree; codes are the way to go.  Parsing text is also a problem because
  86. the user might edit the file (perhaps changing words or changing the
  87. case of the text) and mess everything up.  Numbers parsing is more
  88. efficient anyway.
  89.  
  90.  
  91. -- 
  92. () ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ () ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ()
  93. ()  Michel Forget / Electric Storm Software  ()   My cat stole my       ()
  94. ()   mforget@elfhaven.ersys.edmonton.ab.ca   ()   opinions, and pawned  ()
  95. ()         ess@tibalt.supernet.ab.ca         ()   them off for milk.    ()
  96. () ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ () ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ()
  97.  
  98.